PSR: what the provisional political agreement signals for PSPs
This article is part of our series tracking the developments of the EU’s new payments framework and what it means for the financial industry. The shift from PSD2 to PSR and PSD3 marks a structural change in Europe’s payments landscape, bringing new opportunities but also stricter technical and compliance obligations for banks.
The legislative journey of the Payment Services Regulation (PSR) has entered a decisive phase. Following the fourth political trilogue in November 2025, the European Parliament, the Council and the Commission have announced a provisional political understanding on key elements of the regulation. Technical work is continuing to consolidate the final legal text, confirm drafting choices (including deletions and scope conditions), and finalise mandates for EBA Regulatory Technical Standards (RTS) and Guidelines.
This makes several outcomes more predictable, but the PSR is not final and some drafting choices (including deadlines and scope conditions) remain open. This is the moment to identify which requirements are sufficiently stable to start engineering against, and which ones remain contingent on final wording.
Below is an analysis of some of the current positions, highlighting the evolution from earlier drafts and identifying areas where technical drafting is still finalising the political deal.
Fraud and liability: emerging direction and operational implications
Fraud is the area where the trilogues have been most politically explicit. The emerging model reduces reliance on after-the-fact disputes by strengthening prevention and intervention during the execution phase. This translates into tighter operational expectations across monitoring and detection, intervention (suspension/blocking), evidence gathering and auditability, and coordinated handling across the payment chain.
Impersonation fraud (‘spoofing’): a narrowed scope
The political agreement confirms a move away from the broad impersonation concept (impersonating ‘any relevant entity’) and restricts the refund right to cases of impersonation of the payer’s PSP (or its staff). This specifically covers manipulation via communication channels attributed to the PSP, such as (but not limited to) its name, e-mail address, and telephone number. Regarding the process, the institutions appear to be converging towards a refund/justification window of 15 business days, which starts once the PSP has been notified of the transaction and provided with the police report.
The ‘failure to block’ concept: linking monitoring and liability
A major operational shift is the emerging linkage between transaction monitoring and liability. The current compromise direction introduces the concept that, where a payer’s PSP has objectively justified reasons to suspect fraud and does not suspend/block the transaction, the payer should not bear the financial consequences (subject to the payer not having acted fraudulently). This effectively increases the cost of false negatives and makes the quality and auditability of monitoring-to-intervention decisioning a supervisory and financial risk topic. This is likely to require clearer internal governance: triggers, escalation, customer communications, and a documented reassessment cycle when instruments or transactions are blocked.
Freezing funds at the payee PSP: coordination expectations increase
The compromise direction introduces a structured mechanism for the payee’s PSP to intervene when it has ‘objectively justified reasons’ to suspect that a transaction is fraudulent, based on its transaction monitoring or other relevant information. In such cases, the payee’s PSP may decide not to make the funds available to the payee and instead return the funds to the payer’s PSP.
Upon deciding to return the funds, the payee’s PSP must immediately notify the payer’s PSP of the return and the reasons for refusal. Consequently, the payer’s PSP is obliged to inform the payer (and the PISP, if applicable) that the funds were not made available due to fraud prevention measures and must credit the returned amount back to the payer’s account. Stricter timing applies to instant credit transfers, where the payee’s PSP must notify the payer’s PSP of the refusal and return of funds within 10 seconds of receiving the payment order, triggering a restoration of the payer’s account.
Burden of proof and ‘supporting evidence’: proportionate, standardised case handling
Several provisions aim to balance consumer protection with effective investigation. The working text shows explicit sensitivity about not shifting the burden of proof onto the payment service user (PSU), while still allowing PSPs to request information that the user can reasonably be expected to have. This is likely to translate into a need for standardised, proportionate evidence requests and robust case files that can support refusals, complaints handling and external dispute pathways.
Gross negligence: procedural discipline without rigid definitions
On gross negligence, the negotiation direction appears to avoid an overly rigid ‘one size fits all’ definition through binding technical standards, while still imposing procedural discipline on PSPs (for example, requiring an invitation for the user to provide information before a refusal on gross negligence grounds). Similarly, the loss-of-credentials discussion continues to focus on the boundary between user behaviour and PSP responsibilities in a fraud context, ensuring users are not liable for undetectable theft of credentials unless they acted fraudulently or with gross negligence.
Fraud data sharing: a move towards mandatory participation
Trilogue discussions signal a push from encouragement to a mandatory approach on fraud data sharing. The compromise introduces a provision under which PSPs ‘shall’ exchange data under data-sharing arrangements where there are reasonable and objective grounds to suspect fraud.
Earlier drafts contemplated an EBA IT platform; later drafting trends suggest a move away from a strict central-platform obligation, not least because private-sector solutions are developing in parallel. As a result, PSPs should plan for mandatory participation in decentralised, private-sector or multilateral information-sharing arrangements, rather than a single EU-wide technical utility.
Open Banking: resilience, parity, and fallback
On Open Banking, the compromise direction reads increasingly as a trade-off: the permanent fallback obligation is likely to disappear, but in exchange ASPSPs must deliver a dedicated interface that is operationally comparable to their own customer channels.
Removal of permanent fallback: more scrutiny on the dedicated interface
The consolidated direction points towards a regime where ASPSPs are not obliged to maintain a permanent fallback interface if they operate a compliant dedicated interface. The trade-off is a legal mandate for performance parity: the dedicated interface should meet availability and performance that are at least equal to the interface the ASPSP uses for its own customers. Operationally, this pushes parity from a principle into a measurable control: monitoring, reporting, incident classification and recovery times.
Fraud prevention vs prohibited obstacles: wording remains sensitive
A key compromise element is the clarification that fraud-preventive measures used by ASPSPs should not be treated as prohibited obstacles, provided they are necessary to address suspected fraud. The text remains sensitive at drafting level, which suggests the final wording may seek to balance security controls with the PSR’s objective of effective open banking access.
The provisional political agreement on the PSR clarifies the road ahead: banks are gaining relief from maintaining redundant fallback interfaces, but in return, the bar for API performance is being raised to parity. Failure here is no longer just a technical issue, it becomes a compliance matter.
The wider ecosystem: online platforms and telecoms in the fraud prevention narrative
The PSR negotiations recognise that fraud often starts outside the banking perimeter. The political direction brings providers of hosting services, very large online platforms (VLOPs), very large online search engines (VLOSEs), and electronic communications service providers (ECSPs) into the broader fraud prevention narrative.
Platforms: notification mechanics and potential recourse routes
Trilogue discussions point towards stronger expectations around notice-and-action processes for fraudulent content, and exploring pathways for PSPs to pursue recourse where content remains online despite notification.
Definitions, thresholds and process requirements remain under technical drafting, meaning scope and conditions are not yet fixed. If recourse mechanisms are retained, they will increase the importance of structured evidence collection (what was notified, when, through which channel, and how it connects to a fraud event).
Telecoms: moving towards cooperation duties rather than direct reimbursement
The latest trilogue direction suggests that direct reimbursement liability for ECSPs may be replaced by cooperation duties and technical measures aimed at preventing spoofing, potentially supported by a voluntary code of conduct. For PSPs, the operational relevance is practical: any recourse or cooperation mechanism will depend on reliable records and communication channels across sectors.
Verification of advertisers of financial products: likely direction, mechanism still taking shape
The post-trilogue flash note references a ‘verification of advertisers’ mechanism for VLOPs and VLOSEs, even though this provision is not yet fully populated in the consolidated compromise wording. The likely direction is that certain platforms will be expected to verify that financial services advertisers are appropriately authorised before allowing ads to run, but the precise mechanism and scope of platforms must be treated as under technical drafting.
What to watch as the text is finalised
While the political direction is clearer, technical work continues on specific drafting points and implementation timelines. The points below are illustrative rather than exhaustive, but they are likely to remain important for planning purposes:
- Application date: the implementation timeline is still bracketed in the text, oscillating between 18 and 24 months after entry into force.
- Outsourcing: the text does not yet fully stabilise on whether additional PSR-specific outsourcing requirements apply to SCA-related technical service providers, or whether DORA coverage is treated as sufficient.
- VoP transition: a longer transition period (potentially 24 to 30 months) is being negotiated for the implementation of Verification of Payee for non-euro transfers.
The PSR signals a shift towards a more operationally demanding environment: compliance expectations increasingly translate into measurable performance, robust intervention processes, and auditable decisioning.
How Finologee can support the transition
As a trusted provider of PSD2 compliance and Open Banking infrastructure in Luxembourg with 35 banks and PSPs using its platform, Finologee continues to monitor the evolution of the PSR and PSD3 frameworks closely.
As a Luxembourg-regulated Support PFS, Finologee is uniquely placed to support ASPSPs through this transition. Our existing platform and services already proactively address several requirements that are emerging under the PSR, helping banks adapt efficiently as the framework is finalised. In practice, this includes:
- Parity-ready architecture: our PSD2 Access to Account (XS2A) infrastructure is built on high-availability architecture designed to meet the strict ‘performance parity’ mandates, enabling ASPSPs to prove compliance with the new PSR availability statistics.
- Consent management: the PSR’s new permission dashboard requirement aligns with Finologee’s existing consent lifecycle management tools, which already provide granular visibility into TPP access and permissions.
- Security and SCA integration: operational support for SCA flows and authentication orchestration in complex environments.
By leveraging third-party solutions like Finologee’s platform, banks can reduce the extensive internal IT and compliance workload associated with implementing these complex technical standards and accelerate their compliance roadmap.
